Methods and systems for delivery of compliant video advertisements to devices from one or more platforms including video ad review and approval process

ABSTRACT

A method of approving video advertisements for placement in video content can comprise receiving and ingesting the video advertisements, obtaining a plurality of business rules, creating a database of the business rules, obtaining file information of the video advertisements, obtaining content information about the video advertisements, determining audio codec information and video codec information and/or video data of the video advertisements, determining presence and absence of a unique advertisement identifier of the video advertisements and assigning the unique advertisement identifier to the video advertisements on determining the absence of the unique advertisement identifier, storing video advertisement data in a memory, approving, rejecting and/or rating the video advertisements based on the business rules and the deterministic criteria, providing a web portal that includes user accessibility to the video advertisements and the video advertising data, and providing notification of the availability of new video advertisements for review.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation under 35 U.S.C. § 120 of U.S.application Ser. No. 13/800,876, filed Mar. 13, 2013, which claims thebenefit of U.S. Provisional Application No. 61/619,292 filed on Apr. 2,2012 and U.S. Provisional Application No. 61/719,914, filed on Oct. 29,2012. Each of the above-referenced patent applications is incorporatedby reference in its entirety.

BACKGROUND OF THE INVENTION

The accessibility and consumption of video content over the Internet hasgrown exponentially in recent years. As a result, more and more usershave shifted to watching or accessing video content on and throughInternet-connected devices capable of reaching a variety of videocontent resources spread throughout the world. In connection with thisshift of viewing habits to accessing Internet-based video content, videocontent providers have sought to help monetize and support such videodelivery by incorporating video-based advertisements into and around thevideo content requested by users.

Video content providers would like to know whether a particular videoserved to a user over the Internet is actually received or watched bythe user in its entirety. The ability for users to skip or fast-forwardpast certain videos, or certain portions of videos, means that contentproviders may know only whether a particular video is requested, but notwhether it is actually received or watched by the user. Additionally,many devices do not have the requisite software (player, web kit,browser, etc) to initiate or respond to request from internet serversdelivering and/or logging requests and responses. Such uncertainty as towhether videos are actually watched by the requesting user may limit thedesirability or incentive for many video content producers to make theirvideo content accessible over the Internet. For example, advertisers maydesire to include a short video advertisement around certainhighly-requested videos. However, some devices that stream internevideo, including but not limited to first generation set top boxes(STBs) may not provide sufficient levels of communication to theadvertisers that their advertisements are actually received and watchedby users.

Lacking such communication ability, many advertisers refuse todistribute their advertisements to those devices in connection withonline video content.

As a result, there is a need to provide better information to videoadvertisers regarding delivery of their video content, includingadvertising content, through Internet-connected devices. Before theDigital Video Ad Serving Template (VAST), there was not a commonin-stream advertising protocol for video players, which made scalabledistribution of ads impossible for ad servers. In order to serve ads tomultiple publishers using disparate proprietary video players,ad-serving organizations had to develop slightly different ad responsesfor every publisher/video player targeted. This approach was expensiveand did not easily scale. Additionally, the ad servers could not receivea response from many devices indicating that the ad had been played.

INCORPORATION BY REFERENCE

All publications, patents, and patent applications mentioned in thisspecification are hereby incorporated by reference to the same extent asif each individual publication, patent, or patent application wasspecifically and individually indicated to be incorporated by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating various components of a systemconfigured to provide request, response, and verification of a DigitalVideo Ad Serving Template (VAST), delivery over the Internet.

FIG. 2 is a block diagram illustrating various components of a systemconfigured to provide request, response, and verification of a DigitalVideo Ad Serving Template (VAST), delivery over the Internet, includingsample HTTP and Extensible Markup Language (XML) calls.

FIG. 3 is a block diagram illustrating various components of a systemconfigured to provide an HTTP request over the Internet including sampleHTTP header/user agent information.

FIG. 4 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for non-VAST compliant ad server, and non-VAST compliant set topbox (STB) and a Ad Proxy Server.

FIG. 5 is a block diagram illustrating a Web Server or ElectronicProgram Guide (EPG) Server connecting to VAST Proxy Server viaApplication Programming Interface (API). The computer hardware andcomputer systems usable for implementing the systems and methodsdescribed herein, listing multiple IP connected devices, and a webserver or electronic program guide (EPG) server.

FIG. 6 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for an ad server, an ad network, an ad platform, and non-VASTcompliant set top box (STB), and IP connected devices capable of playingvideo.

FIG. 7 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for a VAST compliant ad server, and non-VAST compliant set topbox (STB), including transrating the video ad clip.

FIG. 8 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for a VAST compliant ad server, and a non-VAST compliant set topbox (STB), including transcoding and transrating the video ad clip.

FIG. 9 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for a VAST compliant ad server, and a VAST compliant ‘smart’phone, including transcoding and transrating the video ad clip, withmultiple bit-rate video clips.

FIG. 10 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for a non-VAST compliant ad server, and a non-VAST compliant IPset-top box (STB), with optional ‘start’ and ‘stop’ ad deliveryverification clips.

FIG. 11 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for an ad server, a VAST compliant IP connected ‘smart’ TV, andverification clip servers, with optional ‘start’ and ‘stop’ ad deliveryverification clips.

FIG. 12 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, for a VAST compliant ad server (1202), and a VAST compliant IPconnected set top box (STB) (1201), with web service aka APIconnectivity between the web server or electronic program guide (EPG)server (1205) and the Ad Proxy Server (1204).

FIG. 13 is a flow chart illustrating a sample timeline of video contentdelivery from the viewers perspective, according to an embodiment.

FIG. 14 is a flow chart illustrating a sample timeline of video contentdelivery from the perspective of one or more ad servers, according to anembodiment.

FIG. 15 is a block diagram illustrating computer hardware and computersystems usable for implementing the systems and methods describedherein, with an ad server, and IP connected devices, with APIconnectivity between the web server or electronic program guide (EPG)server and the Ad Proxy Server, transcoding/transrating servers, and aseparate web server used for manual approval of the ads.

FIGS. 16 and 17 are block diagrams illustrating computer hardware andcomputer systems usable for implementing the systems and methodsdescribed herein.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

Systems and methods for verification and delivery of compliant videoadvertisements to devices by utilizing a proxy server are describedherein.

While various embodiments of the present invention have been shown anddescribed herein, it will be obvious to those skilled in the art thatsuch embodiments are provided by way of example only. Numerousvariations, changes, and substitutions will now occur to those skilledin the art without departing from the invention. It should be understoodthat various alternatives to the embodiments described herein may beemployed in various embodiments.

Content Routing

Various embodiments described herein can be implemented over a network,such as the Internet. The Internet is a network between multipleInternet Service Providers (ISPs). Companies that have content (such ascontent distribution networks) exchange their content with ISPs thathave users attempting to see the content. The ISPs exchange content, orInternet traffic, at peering points and data centers.

One method used for routing between ISPs and content providers is BorderGateway Protocol (BGP). An ISP may route traffic to the destinationInternet Protocol (IP) Address based on how the content provider isannouncing the IP address on the Internet. It is possible for a contentprovider to have one IP address announced, and be present, in multiplephysical locations. These Internet Protocol (IP) addresses may be ineither IPv4 or IPv6 format.

North American and European exchange points are generally in major metroareas, such as Los Angeles, Chicago, New York, London, and Amsterdam. Asan example, assume a content provider is announcing the same publiclyroutable IP address (e.g. 69.1.64.1) in Los Angeles, Chicago, New York,London, and Amsterdam. Also assume that an ISP peered, or exchangedtraffic, in each of those locations with that content provider. The ISPusers in the Western United States should be routed to Los Angeles;whereas the same ISP users in Ireland should be routed to London.

In the event of a network outage in one location, the content providermay stop announcing the route at that location, and BGP routing couldroute ISP users to a different location. For example, if the contentprovider has a network outage in Los Angeles, the ISP may route theirwest coast users to either Chicago or New York. It is difficult andexpensive to exchange traffic, or peer, at each location that both thecontent provider and ISP have peering. For example, a content providermay have ten exchange points in the United States, and only peer with aEuropean ISP in one of those locations. Thus, all of the European ISPusers will be directed to that one exchange point. In some situations,it is impossible for the content provider to peer directly with the ISP.In that case, the traffic will transit through other ISPs or serviceproviders in order to reach its destination. There are severalcommercially available databases that estimate a user's physicallocation based on its IP address. These databases are commonly used bycontent providers to estimate the user's physical location

Content Providers and Content Servers

Internet video streaming starts with content ingestion. Content can bedelivered on tape, DVD, via satellite dish, etc. Content can be anyaudiovisual video capable of being digitally delivered to the user,including without limitation second video ads, two-hour long movies, or24×7 linear channels. The content may then be encoded into a formatcompatible with the viewers' device.

Video clips and movies are stored on video content storage servers. Livefeed is continuously ingested. A playlist tells the master server whichfiles to play, and when. The master server then sends the stream to edgeservers, located in various parts of the world. The viewer connects tothe Internet, and is directed to the DNS server. The DNS server thendirects the viewer to the authentication server, or directly to theelectronic program guide (EPG) server

Content providers may maintain multiple copies of the same content inmultiple servers and multiple locations. These multiple locations areoften referred to as points of presence (POP'S).

It should be understood that the content servers may be loaded withdifferent operating systems and may have multiple software applicationsinstalled and capable of running in connection with the operatingsystem, for facilitating platform functionality.

The content servers may be connected to the Internet and traffic may berouted to the servers' IP Address. The content provider can have one ormore servers per POP. Additionally, the content provider can segmentuser requests and/or responding content traffic at each POP. The serverresponding to the content request is not required to be at the POP wherethe viewer request arrived.

In one aspect of the invention, a user's device may be connected to theInternet and may be used to connect to and receive content from acontent provider. Users can employ various types of devices to connectto the network and Internet. Examples of these devices include but arenot limited to computers, smart phones, tablet computers, smarttelevisions, and television set top boxes. A television set top box is adevice that connects to the Internet and the television's input panel.

When a user's device requests content from a content provider, a numberof variables may be provided to the content provider in connection withthe user's request. For example, the user's request may include one ormore of the following information: User agent, Browser type, InternetProtocol (IP) address, a globally-unique identifier (GUID) that may berepresented, for example, as a 32-character hexadecimal string, UniqueDevice (or viewer) ID, Device Operating System (Windows, Linux, etc),and acceptable languages.

The content server may automatically timestamp the user's request. Afterthe server decides that it can and should provide the requested contentto the user, it will supply the content, and optionally update one ormore database tables documenting the transaction event.

The Interactive Advertising Bureau's (IAB's) Video Ad Serving Template(VAST) specification is a universal XML schema for serving ads todigital video players, and describes expected video player behavior whenexecuting VAST-formatted ad responses. VAST provides a common protocolthat enables ad servers to use a single ad response format acrossmultiple publishers/video players. In 2008, the IAB introduced the firstversion of VAST to the video advertising marketplace, which has sincebeen widely adopted throughout the industry. In 2009 features were addedthat enabled additional functionality and more clarity. Today, as thein-stream digital video advertising market becomes more sophisticated,additional features and functionality are required to improve supportfor in-stream ad display and reporting. However, this protocol relies onan assumed capability of the video device that is not found in many ofthe devices.

The VAST specification includes description of the ad, and the formatfor the delivered ad such as frame size and encoding protocol. Due tothe increase in the number of mobile devices, tablets, gaming consoles,etc a single format will not play on all devices. Further, manyadvertisers have ignored some encoding protocols as they were primarilyused on first generation devices. Thus many of the ads requiretranscoding from one encoding protocol to a different protocol; and/ortransrating from one frame size or bit rate to another; in order to playon all devices.

For purposes of discussion, ‘non-VAST compliant’ device references aninternet connected device that does not have the requisite video player,application or software to produce, send, or receive HTTP signalsrequired to parse a VAST ad server response and use the data, or may beotherwise incapable of creating or processing VAST-compliant requests orresponses.

For purposes of discussion, ‘non-VAST compliant’ ad server references aninternet connected video ad server that either a) does not provide videoclips formatted to meet or b) does not have the software to produce,send, or receive HTTP signals or tracking URLS required to produce anXML schema and/or parse a VAST ad server response and use the data, orc) does not have the software to receive HTTP signal requests or receiveHTTP signals or tracking URLS or to properly parse an XML schema inputand/or parse a tracking URL response and/or requests for video ads frominternet connected devices, and/or error responses.

The principles herein as applied as to interactions between, andnetworks including, combinations of VAST and non-VAST systems may alsoapply to interaction between, and networks including, combinations ofsystems using or with a particular schema or protocol and systems notusing or without the particular schema or protocol. Thus, various otherembodiments using different schema, protocols or systems are possibleaccording to different embodiments.

FIG. 5 is a block diagram illustrating various components of a systemconfigured to provide verification of data delivery over the Internet,according to one embodiment. In one embodiment, the Viewer sends arequest over the Internet to the Web Server for video content. The videocontent can be both live streaming, as well as video on demand (movies,video clips, etc). The Web Server may forward that request to the AdProxy Server. The Ad Proxy Server may perform various security measures,such as authenticating the requesting device and user. The Ad ProxyServer may determine the user agent of the Viewer's device in order todetermine the correct format (mime-type) to serve video clips to theViewer's device. The Ad Proxy Server may determine which video clips areavailable to serve to the Viewer based on business logic and availablespots. The VAST ad proxy Server responds to a user request by returningan ASX file with the appropriate video content references.

The Advanced Stream Redirector (ASX) format is a type of XML metafiledesigned to store a list of Windows Media files to play during amultimedia presentation. It is used frequently on streaming videoservers where multiple video content files are to be played insuccession. A VAST ad proxy Server may support a number of streamingprotocols, such as RTSP, MMS, RTMP, HLS, and HTTP. In some embodiments,ASX files have MIME type video/x-ms-asf. For example, an ASX file mayinclude the following structure:

  <ASX Version = “3.0”>  <ENTRY>   <REF HREF =“mms://server1/welcome1.asf” />  </ENTRY>  <EVENT NAME=“test”WHENDONE=“NEXT”>  </EVENT>  <ENTRY>   <REF HREF =“mms://server1/sample.asf” />  </ENTRY> </ASX>

In some embodiments, the Ad Proxy Server may also create WSX files. AWSX file is an XML file that defines the sequence of ads and media in aplaylist, and provides information as to how they should behave. WSXfiles are used for server-side playlists. For example, WSX file maycontain the following:

  <?wsx version=“1.0”?> <smil>  <seq id=“sq1”>   <media id=“video1”src=“clip1.wmv” />   <media id=“video2” src=“clip2.wmv” />  </seq></smil>

In some embodiments, the Ad Proxy Server may also create m3u8 files. Anm3u8 file is an XML file that defines the sequence of ads and media in aplaylist, and provides information as to how they should behave. m3u8files are used for server-side playlists. For example, m3u8 file maycontain the following:

TABLE-US-00002 #EXTMU3 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=440000http://ll.media.vwxyz.com/adsTarget/Target_440.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=640000http://ll.media.vwxyz.com/ads/Target/Target_640.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=1140000http://ll.media.vwxyz.com/ads/Target/Target_1140.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=1340000http://ll.media.vwxyz.com/ads/Target/Target_1340.m3u8wherein “Target_440.m3u8” may comprise a nested playlist similar to thefollowing:

TABLE-US-00003 #EXTMU3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0#EXTINF:10,http://ll.media.vwxyz.com/ads/Target/Target_440/fileSequence0.ts#EXTINF:10,http://ll.media.vwxyz.com/ads/Target/Target_440/fileSequence1.ts#EXTINF:10,http://ll.media.vwxyz.com/ads/Target/Target_440/fileSequence2.ts#EXT-X-ENDLIST

In some embodiments, the Ad Proxy Server may also create proprietaryquasi-XML files, such as but not limited to Vidillion Markup Language or‘VML’. A VML file is an quasi-XML file that defines the sequence of adsand media in a playlist, plus additional non-VAST template information,and provides information as to how they should behave. VML files areused for server-side playlists, plus transfer of additional data betweenthe VAST ad proxy Server and the ad server, or the video player, or boththe ad server and the video player. For example, VML file may containthe following:

   <?wsx version=“1.0”?>  <smil>   <seq id=“sq1”>    <media id=“video 1”src=“clip1.wmv” />    <media id=“video 2” src=“clip2.wmv” />   </seq> </smil>  <vml>   <Service_Provider>   <Vid_Cust_ID>1000001</Vid_Cust_ID >   </Service_Provider>   <Source>   <Device_IP_Address>10.9.8.7</ Device_IP_Address>   </Source>  <Content>  </vml> <VAST version=“2.0”> </VAST>

VAST Ad Proxy Server

As illustrated in FIG. 5, a user's request for video content, inconnection with an embodiment, may be routed to a VAST ad proxy Server.The VAST ad proxy Server, in response to a user request, generates httpresponses and/or playlists in a format usable by the users video device.These playlists can be ASX, WSX, SMIL, etc files containing a listing ofone or more locations containing the requested or other video contentthat should be accessible to the user's device in response to the user'sinitial request.

VAST ad proxy Server may digitally sign a publisher's media streamingrequests for streams that are protected. For example, the VAST ad proxyServer could sign the stream using a secure token, a password, or ahash. In some embodiments, VAST ad proxy Server may bypass this securitystep if the media streams are protected with Digital Rights Management(DRM) access control. The media servers can then validate that eachstreaming request is authorized, and reject those that are not.

In some embodiments, a user requesting content may be routed to theclosest VAST ad proxy Server. Determination of the closest VAST ad proxyServer may be accomplished using any number of methodologies, including,for example, by use of BGP routing. In some scenarios, the VAST ad proxyServer may use the user's IP address to determine the country or area inwhich the user is located, and may then direct the user to the closestcontent media server based on such country or area. A variety ofapproaches may be used for determining a user's location relative torequested content and for directing a user's request to a server locatedclose to the user's location.

The VAST ad proxy Server may provide the functionality to direct asingle viewer, a small ISP, or a metro area to a specific POP,regardless of distance. The VAST ad proxy Server may provide the contentoperator with the opportunity for granularity in delivering traffic tothe closest POP to the viewer.

In one embodiment, VAST ad proxy Server may be accessed using a singleglobal sub-domain name (host.domainname.net). That sub-domain name mayresolve to a single IP address that is announced globally by the contentprovider via BGP from multiple locations. This routing approach wouldpermit users to be routed to the “nearest” point on the net announcingthe given destination IP when attempting to connect to VAST ad proxyServer's single global sub-domain name.

The use of such a sub-domain name may permit certain failovercapabilities in the VAST ad proxy Server. If there is a network issue inone POP, the content provider discontinues announcing that IP addressfrom that POP, while the single IP address is announced globally via BGPfrom the remainder of the POPs. Thus there is automatic fail-over to adifferent data center, if one server or one data center is inaccessible.

In some embodiments, VAST ad proxy Server may alternatively utilizeAnycast routing methodologies. Anycast is a network addressing androuting methodology in which datagrams from a single sender are routedto the topologically nearest node in a group of potential receivers allidentified by the same destination address.

In addition to the single global sub-domain name, the VAST ad proxyServer in each POP may also have its own local sub-domain name and localIP address. Each data center hosting a VAST ad proxy Server (POP) mayalso have a de specific sub-domain name (e.g. host.domainname.net). Inthis manner, the features and functionality performed by the VAST adproxy Server may be replicated in order to provide high availabilityclusters for reliability and scalability.

According to an embodiment, regardless of which VAST ad proxy Server arequest ends up in, the media URLs embedded in each ASX references thecontent server POP closest to the requester, based on a geo-lookup offof the requester s IP address; or to a POP specified on other criteria.

Traffic Director

One component of the VAST ad proxy Server is Traffic Director. Theobjective of Traffic Director is to determine the location of the user,and then connect the user to the content provider's closest point ofpresence (POP) that has the content that the viewer requested. The VASTad proxy Server may use subdomain names to identify the location of thePOP. For example, the VAST ad proxy Server may use the following:Global: host.domainname.net; Localized:host-poplocationcode.domainname.net.

Poplocation Code is a three character acronym based on the nearest majorairport code. The airport codes are based on the International AirTransport Association airport code. Poplocationcode. Domain-name.netwith the hyphen identifies a POP; containing groups of IPs, where theIPs may change often. The quantity of IPs per area will vary based onload. There are multiple DNS servers for host.domainname.net located inmultiple locations. Viewers in different countries doing a trace routeuse different DNS servers; and may get different results. VAST ad proxymay also use sub-domain names to identify the customer that owns thecontent. For example, the VAST ad proxy may use the following: Global:customemamecode. Domain-name.net; Localized:customernamecode-lax.totalstream.net.

By way of example, viewers tracing tohost-poplocationcode.domain-name.net from New York should resolve to69.1.92.106, 69.1.92.122 IPv4 IP addresses in Ashburn; while viewerstracing to host-poplocationcode.domain-name.net from Los Angeles shouldresolve to 69.1.67.74 IPv4 IP addresses in Los Angeles Total-stream.netwith the hyphen resolves to IPs that are globally announced (The69.1.70.0/24 IPv4 IP addresses network). Viewers tracing tohost.domainname.net will go to the closest VAST ad proxy Server based onBGP routing.

VAST ad proxy sub-domain names can also resolve to other sub-domainnames, by using CNAME records. A CNAME record or Canonical Name recordis a type of resource record in the Domain Name System (DNS) thatspecifies that the domain name is an alias of another, canonical domainname. By doing this, the content provider can direct traffic from othersources, and/or other content providers.

In some embodiments, Traffic Director uses the country codes from ISO3166 to assign countries to POPs, for the purpose of calculatingdistances to the viewer. ISO 3166 is a standard published by theInternational Organization for Standardization (ISO). It defines codesfor the names of countries, dependent territories, special areas ofgeographical interest, and their principal subdivisions (e.g., provincesor states). If a country is not specifically named, it will be routedbased on the continent. Traffic Director utilizes acontinent-country-pop table that maps continents and countries toexisting content providers POPs. As an example, Traffic Director may usethe following ISO 3166 Codes in its table:

Country POP “AD” “customernamecode-ams.domain-name.net” “AE”“customernamecode-lax.domain-name.net” “AF'”“customernamecode-lax.domain-name.net”

In some embodiments, Traffic Director may use the average latitude andlongitude for US States and Canadian Territories for the purpose ofcalculating distances. Large, populous states (e.g. California) aresplit into sections. Traffic Director may use two letter codes torepresent states. A sample list is:

State Latitude Longitude AK 61.3850 −152.2683 AL 32.7990 −86.8073 AR34.9513 −92.3809

In other embodiments, Traffic Director may also use commerciallyavailable databases to estimate the user's physical location, includingbased on IPv4 IP address.

Intermediate Server, or ‘Proxy’ Server, VAST Template and PlaylistCreation

In the standard implementation, an IP connected device (101) playingvideo content will send an HTTP request to a video ad server (102), asillustrated in FIG. 1. This is also known as an URL request. The HTTPrequest contains a string of variables. The ad server (102) will respondwith an XML file, and with a video ad to be played by the IP connecteddevice (101). When the IP connected device (101) completes playing thevideo ad, the IP connected device (101) sends a second HTTP string tothe video ad server (102). The format and data contained within thevarious XML files and XML Schema Definition (“XSD”) is specified in theVAST standard.

FIG. 2 illustrates an example of an HTTP request by the IP connecteddevice (201) with variables, and the ad server (202) XML response. Afterthe video ad is played by the IP connected device (201), it sends asecond HTTP string as shown in FIG. 2. The ad clip format can be indifferent codecs, and in different bit rates, as described inhttp://www.iab.net/media/file/IAB-Video-Ad-Format-Standards.pdf

In some embodiments, IP-connected devices (301) may include otherinformation within the HTTP header of the HTTP request. As shown in FIG.3, this may include, for example, the IP address, user agent, devicetype, browser, operating system, player, etc.

Some IP-connected devices may not contain the necessary applications orsoftware required to make an HTTP request in the format necessary to beVAST compliant, or to process a VAST response. Additionally, some adservers do not provide XML in the format necessary to be VAST compliant.In some embodiments, as illustrated in FIG. 4, an ad proxy server (403)can be used between the IP connected device and the ad server. TheViewer sends a request for content over the Internet that is forwardedto the VAST Proxy server (403). The VAST proxy server (403) may verifythat the user is authenticated to connect to the system, it may verifythat the user with a billing system, it may perform various securitymeasures, it may optionally store the connection information in aseparate database server. The video content can be both live streaming,as well as video on demand (movies, video clips, etc). The ad proxyserver (403) will receive the HTTP requests from the IP connecteddevices, and format an HTTP request to the ad server. In FIG. 4, a settop box (STB) (401) that does not have a player or webkit applicationsoftware necessary to make a VAST compliant HTTP request sends thatrequest to the VAST proxy server. The VAST proxy server creates the HTTPrequest and forwards that request to the ad server (402). In this case,that ad server responds with an XML file that is not VAST compliant, tothe VAST proxy server. The VAST proxy server creates the VAST compliantXML file, and forwards that XML file to the set top box (STB) (401),along with a request for a video ad to the ad server. After the set topbox (STB) (401) plays the ad, it sends an HTTP signal to the VAST Proxyserver, which forwards the HTTP signal to the ad server (402).

In a different embodiment, illustrated in FIG. 5, the IP connecteddevice (501) will make a request for content (to a web page, electronicprogram guide, etc) Video content may be selected by viewers using anyof a variety of, such as by using a remote control or by clicking on ahyperlink. For example, the viewer may select desired video content byusing a remote control in connection with a set-top box, while adifferent viewer may select desired video content by clicking on ahyperlink in a web browser on a PC or a table device. The user mayrequest to view content in a web browser on the device. User opensbrowser and connects to the electronic program guide, or the web pagecontaining the content provider's embedded link. User may be redirectedto the User authentication server, subscriber management system server,or similar The device GUID and http parameters are passed to the server.The web server provides embedded links, containing strings with thechannel ID and other (optional) variables. In response to the userselecting a channel, such as channel 1234, Web server responds with alink containing the viewers channel selection, IP address, stringvariables and sends that to the Ad Proxy Server (504)

The Ad Proxy Server authenticates the request, determines the viewer'sphysical location, determines the closest POP with the content,providers additional security measures, if required, determines if an adis available for this channel, creates the ASX file, then sends that tothe viewer's device. Viewer's device processes the ASX file and presentsViewer with the content identified by the ASX file. In some embodiments,the ASX file will include advertisements for presenting to the Viewerprior to presenting the Viewer with the requested content. Events may bedocumented in an optional logging server.

The ad proxy server (504) will receive the HTTP request from the webpage, electronic program guide, etc, and then the VAST proxy server(504) formats an HTTP request for the ad, and the content. The VASTproxy server creates the HTTP request and forwards that request to thead server (502), including the IP address of the IP connected device(501). The ad server responds with an XML file that is not VASTcompliant, to the VAST proxy server (504). The VAST proxy server createsthe VAST compliant XML file, plus a playlist containing the ad plus therequested content, and forwards that playlist to the IP connected device(501). After the IP connected device (501) plays the ad, it sends anHTTP signal to the video streaming server (506), for the contentoriginally requested from the web page, electronic program guide, etc.

In response to a request for video content by the viewer, the Ad ProxyServer may create an ASX file that includes references to the followingcontent in the specified order:

Video Content Response 2,A - a short video clip from Video ContentServer 2 Video Content Respnse 1,1 - a video clip from Video ContentServer 1 Video Content Response 2,B - a short video clip from VideoContent Server 2

and return that ASX file to the device used by the viewer. Uponreceiving an ASX file response, the viewers device (501) may send videorequests to Video Content Server 2, Video Content Server 1, then VideoContent Server 2, in such order, in order to request viewing of therespective content identified by the ASX file. Those video serversrespond by playing video content in the correct mime-type for therequesting device.

Also shown in FIG. 5 are examples of other IP connected devices,including a ‘smart’ phone and tablet (503), a gaming console (504) and a‘smart’ TV (507). In some embodiments, the smart phone and/or tablet mayalso be used as a remote control for a set top box and/or smart TV, inwhich instance video content may additionally be displayed on saiddevices. Said devices are then referred to as the ‘second screen’. Itshould be understood that any other IP-connected device capable ofdisplaying content such as ads could be utilized in connection with suchembodiments.

References herein to ad servers, ad networks, and ad platforms arereference to any third party advertising platform that is capable ofinterfacing with one or more embodiments set forth herein. FIG. 6 showsthe Ad Proxy Server (601) communicating over the internet to an adservers (603), ad networks (603), and ad platforms (602). Communicationscan be in parallel or serial for request, and parallel or serial forresponse.

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a VAST compatible XML client-side request for content, froman internet connected device. Using business logic, the Ad Proxy Server(601) determines that an ad should be played prior to serving thecontent. Using business logic, built on multiple rule sets such aslocation, time of day, content genre, and other data inputs, the AdProxy Server (601) may then send a request for an ad to ad platform #1(602). Ad platform #1 (602) may then respond with VAST compatible XMLschema with multiple data inputs, including but not limited toavailability of a 15 second ad, ad name, URL, and other data. The AdProxy Server (601) may then create an ASX that includes the ad URL andthe content URL and forwards the ASX to the internet connected device.Upon completion of the ad playing, the Ad Proxy Server may then send anHTTP signal containing VAST compatible XML schema with multiple datainputs to ad platform #1 (602).

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a VAST compatible XML server-side request for content, froman internet connected device. Using business logic, the Ad Proxy Server(601) determines that an ad should be played prior to serving thecontent. Using business logic, built on multiple rule sets such aslocation, day of week, language, and other data inputs, the Ad ProxyServer (601) may then send an HTTP request for an ad to ad platform #1(602), ad network #2 (603), and ad server #3 (604). Ad platform 41 (602)may then respond with VAST compatible XML schema with multiple datainputs, including but not limited to availability of a 15 second ad, adname, URL, and other data; however, it is the first time that thisspecific ad is introduced to the Ad Proxy Server. Ad network #2 (603)may then respond with VAST compatible XML schema with multiple datainputs, including but not limited to availability of a 15 second ad, adname, URL, and other data. Ad server #3 (604) may then respond with VASTcompatible XML schema with multiple data inputs, including but notlimited to availability of a 30 second ad, ad name, URL, and other data.The Ad Proxy Server (601) may then create an ASX that includes the adURLs from Ad network #2 (603) and Ad server #3 (604) and the content URLand forwards the ASX with two ads to the internet connected device. Uponcompletion of both ads playing, the Ad Proxy Server may then send anHTTP signal containing VAST compatible XML schema with multiple datainputs to ad network #2 (603) and Ad server #3 (604). Concurrently, theAd Proxy Server (601) may use business logic to determine whether toforward the new ad from Ad platform #1 to be manually reviewed, and/ortranscoded/transrated, for future use.

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a VAST compatible XML server-side request for content, froman internet connected device. Using business logic, the Ad Proxy Server(601) determines that multiple ads may be played prior to serving thecontent. Using business logic, built on multiple rule sets such asdevice user agent and date of week and other data inputs, the Ad ProxyServer (601) may then send an HTTP request for an ad to ad platform #1(602), ad network #2 (603), and ad server #3 (604). Ad platform #1 (602)may then respond with VAST compatible XML schema with multiple datainputs, including but not limited to availability of a 15 second ad, adname, URL, and other data. Included in the Ad platform #1 response is astated ad value of $0.xx. Ad network #2 (603) may then respond with VASTcompatible XML schema with multiple data inputs, including but notlimited to availability of a 15 second ad, ad name, URL, and other data.Included in the Ad network #2 response is a stated ad value of $0.yy. Adserver #3 (604) may then respond with VAST compatible XML schema withmultiple data inputs, including but not limited to availability of a 30second ad, ad name, URL, and other data. Included in the Ad server #3response is a stated ad value of $0.zz; plus the requirement that the adbe played immediately prior to the content. The Ad Proxy Server (601)may then create an ASX that includes the ad URLs from Ad platform #1(602) first, and Ad server #3 (604) second and the content URL andforwards the ASX with two ads to the internet connected device. Uponcompletion of both ads playing, the Ad Proxy Server may then send anHTTP signal containing VAST compatible XML schema with multiple datainputs to ad platform #1 (602) and Ad server #3 (604).

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a client-side request for content, from an internetconnected device. Using business logic, the Ad Proxy Server (601)determines that a single ad not to exceed 15 seconds may be played priorto serving the content. Using business logic, built on multiple rulesets such as device GUID and ethnic community and other data inputs, theAd Proxy Server (601) may then send an HTTP request for an ad to adplatform #1 (602), ad network #2 (603), and ad server #3 (604). Adplatform #1 (602) may then respond with VAST compatible XML schema withmultiple data inputs, including but not limited to availability of a 15second ad, ad name, URL, and other data. Included in the Ad platform #1response is a stated ad value of $0.xx. Ad network #2 (603) may thenrespond with VAST compatible XML schema with multiple data inputs,including but not limited to availability of a 15 second ad, ad name,URL, and other data. Included in the Ad network #2 response is a statedad value of $0.yy. Ad server #3 (604) may then respond with VASTcompatible XML schema with multiple data inputs, including but notlimited to availability of a 30 second ad, ad name, URL, and other data.Included in the Ad server #3 response is a stated ad value of $0.zz;plus the requirement that the ad be played immediately prior to thecontent. The Ad Proxy Server (601) may then create an ASX that includesthe ad URL from Ad network #2 (603) and the content URL and forwards theASX with two ads to the internet connected device. Upon completion ofthe ad playing, the Ad Proxy Server may then send an HTTP signalcontaining VAST compatible XML schema with multiple data inputs to Adnetwork #2 (603).

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a client-side request for content, from an internetconnected device. Using business logic, the Ad Proxy Server (601)determines that multiple ads not to exceed 60 seconds may be playedprior to serving the content. Using business logic, built on multiplerule sets such as device UID and HTTP referrer agent and other datainputs, the Ad Proxy Server (601) may then send an HTTP request for anad to ad platform #1 (602), ad network #2 (603), and ad server #3 (604).Ad platform #1 (602) may then respond with VAST compatible XML schemawith multiple data inputs, including but not limited to availability ofa 15 second ad, ad name, URL, and other data. Included in the Adplatform #1 response is a stated ad value of $0.xx. Ad network #2 (603)may then respond with VAST compatible XML schema with multiple datainputs, including but not limited to availability of a 15 second ad, adname, URL, and other data. Included in the Ad network #2 response is astated ad value of $0.yy. Ad server #3 (604) may then respond with VASTcompatible XML schema with multiple data inputs, including but notlimited to availability of a 30 second ad, ad name, URL, and other data.Included in the Ad server #3 response is a stated ad value of $0.zz;plus the requirement that the ad be played immediately prior to thecontent. However, the ad server responses are not received in a timelyfashion, so the Ad Proxy Server (601) may then create an ASX thatincludes only the content URL and forwards the ASX with no ads to theinternet connected device. The Ad Proxy Server may then send an HTTPsignal containing VAST compatible XML schema with multiple data inputsto the ad servers.

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a non-VAST compatible XML client-side request for content,from an internet connected device. Using business logic, the Ad ProxyServer (601) determines that an ad should be played prior to serving thecontent. Using business logic, the Ad Proxy Server (601) may then send arequest for an ad to ad platform #1 (602). Ad platform #1 (602) may thenrespond with non-VAST compatible XML schema with multiple data inputs,including but not limited to availability of a 15 second ad, ad name,URL, and other data. The Ad Proxy Server (601) may then create anon-VAST compatible XML that includes the ad URL and the content URL andforwards it to the internet connected device. Upon completion of the adplaying, the Ad Proxy Server may then send an HTTP signal containingnon-VAST compatible XML schema with multiple data inputs to ad platform#1 (602).

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a non-VAST compatible XML client-side request for content,from an internet connected device. Using business logic, the Ad ProxyServer (601) determines that an ad should be played prior to serving thecontent. Using business logic, the Ad Proxy Server (601) may then send arequest for an ad to ad platform #1 (602). Ad platform #1 (602) may thenrespond with VAST compatible XML schema with multiple data inputs,including but not limited to availability of a 15 second ad, ad name,URL, and other data. The Ad Proxy Server (601) may then create anon-VAST compatible XML that includes the ad URL and the content URL andforwards it to the internet connected device. Upon completion of the adplaying, the Ad Proxy Server may then send an HTTP signal containingVAST compatible XML schema with multiple data inputs to ad platform #1(602).

As an example, in some embodiments, the Ad Proxy Server (601) in FIG. 6may receive a VAST compatible XML client-side request for content, froman internet connected device. Using business logic, the Ad Proxy Server(601) determines that an ad should be played; however, the content isnot to be served. Using business logic, the Ad Proxy Server (601) maythen send a request for an ad to ad platform #1 (602). Ad platform #1(602) may then respond with VAST compatible XML schema with multipledata inputs, including but not limited to availability of a 15 secondad, ad name, URL, and other data. The Ad Proxy Server (601) may thencreate a VAST compatible XML that includes the ad URL but not thecontent URL and forwards it to the internet connected device. Uponcompletion of the ad playing, the Ad Proxy Server may then send an HTTPsignal containing VAST compatible XML schema with multiple data inputsto ad platform #1 (602 ).

In some embodiments, the ad server (702) in FIG. 7 will provide therequested ad in a frame size, or encoded bit rate that is sub-optimalfor the IP connected device (701). For that instance, the ad will betransrated to the proper frame size, and bit rate by thetranscoding/transrating servers (703). As an example, in FIG. 7, adserver #1 (702) provides an ad encoded in *.wmv file format at anencoding bit rate of 1 mbps, with a 640×360 frame size. The transcodingserver (703) transcodes that file to a *.wmv file format at an encodingbit rate of 567 kbps, with a 640×480 frame size; for delivery to theset-stop box (701).

In one embodiment, the viewer selects the desired video content, such asby using a remote control. The electronic program guide server (806)forwards that request to the Ad Proxy Server (806). The Ad Proxy Server(806) may perform various security measures, such as authenticating therequesting device and user. The Ad Proxy Server (2704) may determine theuser agent of the device in order to determine the correct format(mime-type) to serve video clips to the viewer's device. The Ad ProxyServer (804) may determine which video clips are available to serve tothe viewer based on business logic and available spots. The Ad ProxyServer (804) responds to a user request by returning an ASX file withthe appropriate video content references.

The ad server (802) in FIG. 8 may provide the requested ad in a codec,frame size, or encoded bit rate that may be sub-optimal for the IPconnected device (801). For that application, the ad will be transcodedand/or transrated to the proper codec, frame size, and bit rate bytranscoding servers (803). As an example, in FIG. 8, ad server #2 (802)provides an ad encoded in *.flv file format at an encoding bit rate of 2mbps, with a 640×483 frame size. The transcoding server (803) transcodesthat file to a *.wmv file format at an encoding bit rate of 567 kbps,with a 640×480 frame size; for delivery to the set-stop box (801).

In some embodiments, the ad server (902) in FIG. 9 will provide therequested ad in a codec, frame size, encoded bit rate, or multiple bitrates, that is sub-optimal for the IP connected device (901). For thatapplication, the ad will be transcoded and/or transrated to the propercodec, frame size, and multiple bit rates by transcoding servers (903).As an example, in FIG. 9, ad server #3 (902) provides an ad encoded in*.mp4 file format at an encoding bit rate of 1 mbps, at 108P. Thetranscoding server (903) transcodes that file to a multiple files, allwith *.M3U8 file formats, at encoding bit rates of 128, 256, at 512kbps, with a 128×96 frame size; for delivery to the smart phone (901)which has an IOS operating system. The VAST proxy server (904) createsSynchronized Multimedia Integration Language (SMIL) playlist rather thanan XML playlist.

In some embodiments, the an optional verification clip server (1004)shown in FIG. 10 will provide a short clip encoded in the same format,bit rate, and codec as the ad, immediately before and immediately afterthe ad, to the IP connected device (1001).

FIG. 10 illustrates a subset of the steps taken to verify content inaccordance with an embodiment. User may connect a device to the Internetvia the user's ISP. Device (1001) is either assigned via DHCP, oralready has, an IP address. Content provider may make the contentavailable by connecting server (1002) to the Internet and assigning apublicly routable Internet Protocol (IP) address. Content provider mayupdate DNS server with a sub-domain name for the content location.Content provider may update the Ad Proxy Server (1005) with the POPlocation for the content, or the URL to the content. A library of‘start’ and ‘end’ verification clips may be uploaded to verificationserver (1004). User may connect (1001) to the content provider'sembedded Uniform Resource Locator (URL).

User may be redirected to the User authentication server, subscribermanagement system server, or similar The device GUID and HTTP parametersare passed to the EPG server (2302). The EPG server (2302) providesembedded links or URLs, containing strings with the channel ID and othervariables. User (2301) selects channel ‘ABCD.’ EPG server (2302)responds with a link containing the viewers channel selection, IPaddress, string variables and forwards that string to the VAST ad proxyServer. VAST ad proxy Server (2304) may perform one or more stepsrelated to the request, such as one or more of the following:authenticating the request, determining the viewer's physical location,determining the closest POP with the requested content, providingadditional security measures if required, determining if an ad isavailable for the requested channel, creating an ASX file, sending thatASX file to the viewers device (2301), and holding an ASX file in memoryas a session variable embedded in an URL. For example, the VAST ad proxyServer log files (2704) may be moved to the Log Server every 2 hours,while the log files from Video Content Server 1 (2706) may be moved tothe Log Server every 30 minutes.

By way of example, as illustrated in FIG. 10, the viewer may request towatch channel “ABCD” by selecting such channel from an EPG. In response,the viewer's device (1001) may be presented first with the video“verificationclipstart.wmv” for 1/10 second from verification clipServer (1004). The viewer may then be presented second content “ad1.wmv”from Video Content Server 1 (1002). The viewer may then be presentedvideo content verificationclipend.wmv” for 1/10 second from verificationclip Server (1004). Finally, the viewer may be presented with theinitially requested content. In some scenarios, the viewer's playerapplication (1001) may call for a key from a DRM server prior to playingthe remainder of the content.

An example of the start and end clips is shown in additional detail inFIG. 11.

In some embodiments, the viewers second screen device (1206), shown inFIG. 12, will be used as a remote control to select content from the webserver or electronic program guide (EPG) server (1205). The request forcontent to be displayed on the IP connected device, the ‘first screen’(1201) may be made by a second IP connected device (1206) the ‘secondscreen’, said request for content (to a web page, electronic programguide, etc) Video content may be selected by viewers using any of avariety of, such as by using a remote control or by clicking on ahyperlink. For example, the viewer may select desired video content byusing a remote control programmed within a smart phone or tablet (1206)in connection with a set-top box or smart TV, while a different viewermay select desired video content by clicking on a hyperlink in a webbrowser on a PC other IP connected device. The user may request to viewcontent in a web browser on the ‘second screen’ device. User opensbrowser and connects to the electronic program guide, or the web pagecontaining the content provider's embedded link. User may be redirectedto the User authentication server, subscriber management system server,or similar The ‘first screen’ and ‘second screen’ device GUID and httpparameters may be passed to the web or EPG server. The web or EPG serverprovides embedded links, containing strings with the channel ID andother (optional) variables. In response to the user selecting a channel,such as channel 1234, Web or EPG server responds with a link containingthe viewers channel selection, IP address, string variables, and otherdata, and sends that to the Ad Proxy Server (1204) via XML, or otherprotocol.

The customers' web server or electronic program guide (EPG) server(1205), shown in FIG. 12, will be in a different location and/or on adifferent network, and may call the Ad Proxy Server (1204) using a WebService or application programming interface (API), or programmingscript.

As an example of this embodiment, the web server or electronic programguide (EPG) server (1205) may transmit or deliver the channel line-up,or list of TV stations available, or the list of video clips presentableto the viewers (list of available video content) to the VAST ad proxyserver (1204). Said transmittal or delivery list of available videocontent may be done in a one-off fashion; on a timed basis per minute,hour, day, week, or month; in advance of known events; in advance ofrequests for video content; concurrent with requests for content; orafter requests for video content. Said transmittal or delivery list ofavailable video content may also in part be derived from third-partycommercial or community sources. The transmittal or delivery list ofavailable video content may be done by physical transfer of media, orvia the interne, or via other method of IP delivery, regardless ofprotocols. Said protocols or methods may included, but are not limitedto HTTP, UDP, FTP, named pipes, specific ports, database transfer, ODBC,BON, XML, spreadsheet transfer, RSS, news feed, etc. Said transmittal ordelivery list of available video content may include, but not be limitedto, channel name, content title, content description, date, time,language, genre, ethnic community, MPAA (or equivalent) rating, userrating, third party rating, cast, director and producer, show time, showduration, suggested time and/or timeframe to deliver the show, and otherdata inputs. Said transmittal or delivery list of available videocontent may include whether to display an advertisement, restrictions onadvertisements, types of advertisements, recommended advertisementformat and encoding (e.g. h264, wmv9, vp6, vp8, etc.), minimum andmaximum bitrate for ads on this channel (based on first screen, secondscreen, etc), mimetype: (e.g. video/mp4, video/x-flv, video/x-ms-wmv,etc.), minimum and maximum advertising duration per advertisement spotor opportunity, maximum ads displayed per variable (per channel, perhour, per viewer, per day, per month, per campaign, etc), maximum adcount (per channel, per hour, per viewer, per day, per month, percampaign, etc), time of day or day of week restrictions for displayingads, locations to place the ad (pre-roll, mid-roll, end-roll, overlay,etc), location to display the ad (first screen, second screen, etc),etc. Said transmittal or delivery list of available video content mayinclude but not be limited to a blacklist of countries where ads shouldnot run, or a whitelist of countries where ad should run. Saidtransmittal or delivery list of available video content may include butnot be limited to a target demographics, a list of traditional genderand age based ad targeting groups (e.g. M18-24, W25-34, A65+, etc.),target zip code, city, state and/or country, or other location input, orother viewer demographic information. Said transmittal or delivery listof available video content may include but not be limited to ID codes,such as publisher, channel, content, system, identification codes. Saidtransmittal or delivery list of available video content may include butnot be limited to delivery, partial delivery, and error codes for firstor second screen devices. Said transmittal or delivery list of availablevideo content may include but not be limited to aspect ratio of programcontent, (16:9, 4:3, etc), vertical resolution of program content, (480,720, 1080, etc), whether the ad may be downscaled, whether or not theplayer can accept ads with a vertical resolution higher than the content‘resolution’, upscale: whether or not the player can accept ads with avertical resolution lower than the content ‘resolution’, and other videoclip altering inputs. Said transmittal or delivery list of availablevideo content may include standard, default, error, and alternative datafor each input. Said transmittal or delivery list of available videocontent may include standard, default, error, and alternative responses.Said transmittal or delivery list of available video content may includestandard, default, error, and alternative URL responses. Saidtransmittal or delivery list of available video content may includeinformation only about the video player type, or model information. Saidtransmittal or delivery list of available video content may includeinformation only about the system. Said transmittal or delivery list ofavailable video content may be corrupt, or not include validinformation. Should said transmittal or delivery list of available videocontent be done over the interne, then the HTTP (or other protocol)referrer information will also be available as inputs to the Ad ProxyServer.

As an example of this embodiment, the Ad Proxy Server (1204) may usesome, part, or all of the data inputs; and then using business logic,determine whether to provided the requested content to the viewersprimary device (1201), and if available to their second device (1206),and if so; whether to also provide video advertising to the viewersfirst or second screen device.

As an example of this embodiment, the Ad Proxy Server (1204) may haveinputs from one or more ad servers, ad networks, or ad platforms (1202)including but not limited to availability of video advertisements; VASTrequests and responses; channel, system, publisher, genre, and otheridentification codes; as well as location restrictions, pricing, viewerdemographic targets, format, and other data inputs. Said transmittal ordelivery inputs of available video advertisements may be done in aone-off fashion; on a timed basis per minute, hour, day, week, or month;in advance of known events; in advance of requests for videoadvertisements; concurrent with requests for advertisements; or afterrequests for video advertisements.

As an example of this embodiment, the Ad Proxy Server (1204) may usebusiness logic, the inputs from the ad servers, ad networks, or adplatforms (1202), and the inputs from the web server or electronicprogram guide (EPG) server (1205), as well as inputs derived fromthird-party commercial or community sources, in combination orseparately, to determine if one, some, or all of the available adservers, ad networks, or ad platforms (1202) shall be sent a request fornone, one, or multiple advertisements, along with some or all of thedata available from above, destined to be displayed on the viewers firstscreen device (1201), second screen device (1206), or both devices.

As an example of this embodiment, the Ad Proxy Server (1204) may usebusiness logic, data inputs, and programming scripts, to create an XMLrequest to the ad servers, ad networks, or ad platforms (1202)requesting one or more advertisements. Said XML request may or may notbe VAST compliant.

As an example of this embodiment, one or more of the ad servers, adnetworks, or ad platforms (1202) may return an XML response to the AdProxy Server (1204) which may include attributes as to the availability,name, URL(s), duration, pricing, location and other data inputs. SaidXML response may or may not be formatted in compliance with the VASTtemplate as described above. The Ad Proxy Server (1204) may then usebusiness logic to determine if to serve one or more of the availableadvertisements to the viewers first screen device, second screen device,or both; and if there are multiple advertisements available, determinewhich order to display some or all of said advertisements. The Ad ProxyServer (1204) may then use business logic and application programming tocreate a playlist consisting of none, or one or more advertisements,plus the URL of the requested content, plus additional information, andforward that playlist to the viewers first screen device, second screendevice, or both. Upon completion of the viewing of the advertisement onthe first screen device, the second screen device, or both; or uponinitiation of viewing of the requested content; the Ad Proxy Server maythen send an HTTP signal to the ad platforms indicating no advertisementwas viewed, that the ad was partially viewed, or the ad(s) werecompletely viewed, on the first screen device, the second screen device,or both.

As a further example of this embodiment in FIG. 12, the sequence ofevents discussed in FIG. 6 in so far as first appearance of an ad,requirements for transcoding, and/or transrating the ad in differentcodecs or formats, storage of various renditions of the ad, for deliveryto the first screen device and/or second screen device may also beapplicable here.

As a further example of this embodiment in FIG. 12, the Ad Proxy Server(1204) may use programming to modify the HTTP or XML or other response(or request) from the ad server (1202), which may be formatted in afashion not compatible with the VAST template, into a VAST compliantresponse (or request); as long as the same ad is delivered to theoriginal requesting device(s). This is accomplished either by a)substituting a VAST compliant template with the original XML data forthe non-compliant template presented, or b) substituting alternativedata inputs into the VAST compliant template which will not impact theoriginally requested ad to the original device, or c) substitutingalternative data inputs into the non-VAST compliant template which willnot impact the originally requested ad to the original device, and usingthose inputs in a VAST compliant template.

As an additional example of this embodiment in FIG. 12, the Ad ProxyServer (1204) may use programming to modify the HTTP or XML or otherresponse (or request) to the ad server (1202), which may be formatted ina fashion not compatible with the VAST template, into a VAST compliantresponse (or request); as long as the same ad server is used fordelivery of the ad to the original requesting device(s). This isaccomplished either by a) substituting a VAST compliant template withthe original XML data for the non-compliant template presented, or b)substituting alternative data inputs into the VAST compliant templatewhich will not impact the originally requested ad to the originaldevice, or c) substituting alternative data inputs into the non-VASTcompliant template which will not impact the originally requested ad tothe original device, and using those inputs in a VAST complianttemplate.

The Ad Proxy Server (1204) may then use business logic and applicationprogramming to record the event(s); and/or to store the event(s)information in a database and/or logging server.

The Ad Proxy Server (1204) may then use business logic and applicationprogramming to send the event information to a third party server.

FIG. 13 is a flow diagram showing the steps to deliver videoadvertisements and content as illustrated in FIG. 8 along a timeline, tothe viewer, according to an embodiment. Upon an HTTP request fromviewers device to watch channel “ABCD” by selecting such channel from anEPG (806), the Ad Proxy Server may respond with an ASX file asillustrated in FIG. 2. Note that said request may be from a seconddevice, such as a remote control, smart phone, tablet, etc. Inaccordance with the contents of the ASX file, the viewers device (801)may be presented with an ad named “ad1.wmv” at approximately time 0.2,which video may play for 15 seconds. Viewers device may then bepresented “transcodedad93.mp4” from a different ad platform atapproximately time 15 2/10, which video may play for 30 seconds.Finally, viewers device may be presented with the initially requestedcontent from channel “ABCD” from Video Content Server 4 at time 45 2/10,which video may play to its completion. The VAST ad server will thenpost an HTTP completion response to both ad servers, at approximatelytime 45 3/10. In some embodiments, information about the advertisementsand content may be recorded in a log file. In some embodiments, the logfiles may be transferred to the Log Server for processing and reportingpurposes.

FIG. 14 is a flow diagram showing the steps to deliver videoadvertisements and content as illustrated in FIG. 8 along a timeline,demonstrating calls and responses from the electronic program guideserver (806) to the Ad Proxy Server (804) to multiple ad servers, adplatforms, and/or ad networks (802) according to an embodiment. Upon anHTTP request from viewers device to the electronic program guide server(806), said request is forwarded (redirected) to the Ad Proxy Server(804) which may include additional optional HTTP, user, or otherinformation, to watch channel “ABCD”. By selecting such channel from anEPG (806), the Ad Proxy Server (804) may enact business logic, includingbut not limited to security, location, ethnic community, language,content genre, device UID/GUID, device user agent, HTTP referrerproperties, date, day of month, time of day, availability of content,availability of advertisements from specific sources, and other inputs,the Ad Proxy Server (804) may respond with a determination as to whetherto serve an advertisement and/or content. The Ad Proxy Server (804) mayalso enact subroutines that determine request time, and start a counterto terminate the following requests and either not return content to theviewers device; or to return content to the viewers device without anadvertisement. Upon determination to serve an ad to the viewer, the AdProxy Server (804) will then determine if more then one ad is to beserved, and if so, repeat the following processes until the total numberof ad requests are fulfilled. The Ad Proxy Server (804) may then submitsingular or multiple HTTP ‘get’ requests to a deterministic quantity ofad servers, ad platforms, and/or ad networks (802), singularly, inserial process, or in parallel process. Alternatively, the Ad ProxyServer (804) may then submit HTTP ‘get’ requests to a single ad servers(802), singularly. One or more ad servers, ad platforms, and/or adnetworks (802) may respond to the HTTP requests. Using business logic,the Ad Proxy Server (804) may then determine if the response isacceptable based on business criteria, including but not limited toresponse format, ad type and ad format, if the ad has been playedbefore, if the viewer has already seen the ad, how many times or howoften the viewer has seen the ad, and other business criteria or inputs.Using business logic, the Ad Proxy Server (804) may then prioritize theresponses, ranking the ads based on inputs including but not limited toad value ($/CPM, etc) campaign fulfillment requirements, and otherinputs. The Ad Proxy Server (804) may then create a playlist in anappropriate language for the device, such as ASX or SMIL. Optionally, ifthis is the first time the ad has entered the system, the Ad ProxyServer (804) may use business logic to not serve the ad, until the adhas been manually reviewed. The manual review of the ad may be performedfrom an optional manual review web server (1401). Said manual reviewshall use deterministics including but not limited to business criteria,competitive information, cultural sensitivities, and other criteria.Optionally, if this is the first time the ad has entered the system, theAd Proxy Server (804) may use business logic to not serve the ad, untilthe ad has been transcoded and/or transrated using atranscoding/transrating server (1406). The transcoding and/ortransrating of the ad will change the ad file format to differentformats, appropriate for delivery to multiple IP connected devices.(801). Concurrently, the Ad Proxy Server (804) may create an ASX file asillustrated in FIG. 2. In accordance with the contents of the ASX file,the viewers device (801) may be presented with an ad named “ad1.wmv” atapproximately time 0.2, which video may play for 15 seconds. Viewersdevice may then be presented with a second ad “transcodedad93.mp4” froma different ad platform at approximately time 15 2/10, which videoadvertisement may play for 30 seconds. Finally, viewers device may bepresented with the initially requested content from channel “ABCD” froma separate video content server at time 45 2/10, which video may play toits completion. The VAST ad server will then post an HTTP completionresponse to both ad servers, at approximately time 45 3/10. In someembodiments, information about the advertisements and content may berecorded in a log file. In some embodiments, the log files may betransferred to the Log Server for processing and reporting purposes.

The systems and methods described herein may be used for a variety ofuses and applications in which verification of content delivery isdesirable. For example, the systems and methods described herein may beused to provide verification to third party advertisers who wish todistribute video advertisements in connection with other video contentover the Internet. In some embodiments, a VAST proxy ad Server mayautomatically include an advertisement with a request for other videocontent, and may include Start Verification Clip and End VerificationClip in a playlist transmitted to a user's device for purposes ofverifying delivery of the advertisement.

The systems and methods described herein may be implemented in or uponcomputer systems, such as the computer systems shown in FIGS. 16 and 17.For example, the system shown in FIG. 1 may be implemented in or uponsuch computer systems. Such computer systems may include variouscombinations of central processor or other processing device, aninternal communication bus, various types of memory or storage media(RAM, ROM, EEPROM, cache memory, disk drives etc.) for code and datastorage, and one or more network interface cards or ports forcommunication purposes. The systems and methods described herein mayinclude or be implemented in software code, which may run on suchcomputer systems or other systems. For example, the software code may beexecutable by a computer system, for example, that functions as thestorage server or proxy server, and/or that functions as a user'sterminal device. During operation the code may be stored within thecomputer system. At other times, the code may be stored at otherlocations and/or transmitted for loading into the appropriate computersystem. Execution of the code by a processor of the computer system mayenable the computer system to implement the methods and systemsdescribed herein.

FIGS. 16 and 17 provide examples of functional block diagramillustrations of computer hardware platforms, in or upon which systemsand methods described herein may be implemented (for example the systemof FIG. 1). FIG. 16 shows an example of a network or host computerplatform, as may be used to implement a server, according to anembodiment. FIG. 17 shows a computer with user interface elements, asmay be used to implement a personal computer or other type of workstation or terminal device according to an embodiment, although thecomputer of FIG. 17 may also act as a server depending on itsconfiguration. The computer system of FIG. 17 may communicate with othersystems through a computer network. For example, computer system of FIG.17 may communicate with the server shown or other systems or servers.The computer system of FIG. 17 may communicate with various otherdevices such as personal computers, tablet computers, personal digitalassistants, mobile telephones and other systems. The systems and methodsdescribed herein may be implemented in or upon such computer hardwareplatforms in whole, in part, or in combination. For example, aspects ofthe systems and methods described herein involving transmission or othersharing of data between systems may be implemented on systems such asthe server of FIG. 16 and the server and computer combination of FIG.17. The systems and methods described herein, however, are not limitedto use in such systems and may be implemented or used in connection withother systems, hardware or architectures. The methods described hereinmay be implemented in computer software that may be stored in thecomputer systems and servers described herein.

A computer system or server, according to various embodiments, mayinclude a data communication interface for packet data communication.The computer system or server may also include a central processing unit(CPU), in the form of one or more processors, for executing programinstructions. The computer system or server may include an internalcommunication bus, program storage and data storage for various datafiles to be processed and/or communicated by the server, although thecomputer system or server may receive programming and data via networkcommunications. The computer system or server may include varioushardware elements, operating systems and programming languages. Theserver or computing functions may be implemented in various distributedfashions, such as on a number of similar or other platforms.

The computer system may also include input and output (I/O) devices suchas a mouse, game input device or controller, display, touch screen orother I/O device or devices in various combinations.

The methods described herein may be implemented in mobile devices suchas mobile phones, mobile tablets and other mobile devices with variouscommunication capabilities including wireless communications, which mayinclude radio frequency transmission infrared transmission or othercommunication technology. Thus, the hardware described herein mayinclude transmitters and receivers for radio and/or other communicationtechnology and/or interfaces to couple to and communication withcommunication networks.

The methods described herein may be implemented in computer softwarethat may be stored in the computer systems including a plurality ofcomputer systems and servers. These may be coupled over computernetworks including the Internet. Accordingly, an embodiment includes anetwork including the various system and devices coupled with thenetwork.

Further, various methods and architectures as described herein, such asthe various processes described herein or other processes orarchitectures, may be implemented in resources including computersoftware such as computer executable code embodied in a computerreadable medium, or in electrical circuitry, or in combinations ofcomputer software and electronic circuitry.

Aspects of the systems and methods described herein may be implementedas functionality programmed into any of a variety of circuitry,including programmable logic devices (PLDs), such as field programmablegate arrays (FPGAs), programmable array logic (PAL) devices,electrically programmable logic and memory devices and standardcell-based devices, as well as application specific integrated circuits(ASICs). Some other possibilities for implementing aspects of thesystems and methods include: microcontrollers with memory, embeddedmicroprocessors, firmware, software, etc. Furthermore, aspects of thesystems and methods may be embodied in microprocessors havingsoftware-based circuit emulation, discrete logic (sequential andcombinatorial), custom devices, fuzzy (neural network) logic, quantumdevices, and hybrids of any of the above device types. Of course theunderlying device technologies may be provided in a variety of componenttypes, e.g., metal-oxide semiconductor field-effect transistor (MOSFET)technologies like complementary metal-oxide semiconductor (CMOS),bipolar technologies like emitter-coupled logic (ECL), polymertechnologies (e.g., silicon-conjugated polymer and metal-conjugatedpolymer-metal structures), mixed analog and digital, etc.

It should be noted that the various functions or processes disclosedherein may be described as data and/or instructions embodied in variouscomputer-readable media, in terms of their behavioral, registertransfer, logic component, transistor, layout geometries, and/or othercharacteristics. Computer-readable media in which such formatted dataand/or instructions may be embodied include, but are not limited to,non-volatile storage media in various forms (e.g., optical, magnetic orsemiconductor storage media) and carrier waves that may be used totransfer such formatted data and/or instructions through wireless,optical, or wired signaling media or any combination thereof. Examplesof transfers of such formatted data and/or instructions by carrier wavesinclude, but are not limited to, transfers (uploads, downloads, email,etc.) over the Internet and/or other computer networks via one or moredata transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When receivedwithin a computer system via one or more computer-readable media, suchdata and/or instruction-based expressions of components and/or processesunder the systems and methods may be processed by a processing entity(e.g., one or more processors) within the computer system in conjunctionwith execution of one or more other computer programs.

Unless specifically stated otherwise, as apparent from the followingdiscussions, it is appreciated that throughout the specification,discussions utilizing terms such as “processing,” “computing,”“calculating,” “determining,” or the like, may refer in whole or in partto the action and/or processes of a processor, computer or computingsystem, or similar electronic computing device, that manipulate and/ortransform data represented as physical, such as electronic, quantitieswithin the system's registers and/or memories into other data similarlyrepresented as physical quantities within the system's memories,registers or other such information storage, transmission or displaydevices. It will also be appreciated by persons skilled in the art thatthe term “users” referred to herein can be individuals as well ascorporations and other legal entities. Furthermore, the processespresented herein are not inherently related to any particular computer,processing device, article or other apparatus. An example of a structurefor a variety of these systems will appear from the description herein.In addition, embodiments of the invention are not described withreference to any particular processor, programming language, machinecode, etc. It will be appreciated that a variety of programminglanguages, machine codes, etc. may be used to implement the teachings ofthe invention as described herein.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words ‘comprise,’ comprising,' and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in a sense of ‘including,but not limited to.’ Words using the singular or plural number alsoinclude the plural or singular number respectively. Additionally, thewords ‘herein,’ ‘hereunder,’‘above,’ ‘below,’ and words of similarimport refer to this application as a whole and not to any particularportions of this application. When the word ‘or’ is used in reference toa list of two or more items, that word covers all of the followinginterpretations of the word: any one or more of the items in the list,all of the items in the list and any combination of the items in thelist.

The above description of illustrated embodiments of the systems andmethods is not intended to be exhaustive or to limit the systems andmethods to the precise form disclosed. While specific embodiments of,and examples for, the systems and methods are described herein forillustrative purposes, various equivalent modifications are possiblewithin the scope of the systems and methods, as those skilled in therelevant art will recognize. The teachings of the systems and methodsprovided herein can be applied to other processing systems and methods,not only for the systems and methods described above.

The elements and acts of the various embodiments described above can becombined to provide further embodiments. These and other changes can bemade to the systems and methods in light of the above detaileddescription.

In general, in the claims, the terms used should not be construed tolimit the systems and methods to the specific embodiments disclosed inthe specification and the claims, but should be construed to include allprocessing systems that operate under the claims.

While certain aspects of the systems and methods are presented below incertain claim forms, the inventors contemplate the various aspects ofthe systems and methods in any number of claim forms. Accordingly, theinventors reserve the right to add additional claims after filing theapplication to pursue such additional claim forms for other aspects ofthe systems and methods.

The various features described above may be combined in variouscombinations. Without limitation, features described may be combinedwith various systems, methods and products described. Withoutlimitation, multiple dependent claims may be made based on thedescription herein.

While embodiments of the invention have been shown and described herein,those skilled in the art will appreciate that such embodiments areprovided by way of example only. Numerous variations, changes, andsubstitutions will now occur to those skilled in the art withoutdeparting from the invention. It should be understood that variousalternatives to the embodiments of the invention described herein may beemployed in practicing the invention.

What is claimed is:
 1. A method of approving video advertisements forplacement in video content, the method comprising: receiving andingesting the video advertisements from a server coupled to a network orfrom digital media connected to a workstation; obtaining a plurality ofbusiness rules from at least one content publisher or outside source andutilizing the plurality of business rules for classifying the videoadvertisements; creating a database of the business rules comprising ahierarchy of deterministic criteria and a plurality of methodologies forthe video advertisements; obtaining file information of the videoadvertisements including at least one of file size, file creation date,file name, file location, file type, and file source; obtaining contentinformation about the video advertisements including at least one ofcontent category, content rating, content author, and time duration;determining audio codec information and video codec information and/orvideo data of the video advertisements; determining presence and absenceof a unique advertisement identifier of the video advertisements andassigning the unique advertisement identifier to the videoadvertisements on determining the absence of the unique advertisementidentifier; storing video advertisement data in a memory, the videoadvertisement data comprising the file information, content information,audio codec information, video codec information and/or video data, andunique advertisement identifiers; approving, rejecting and/or rating thevideo advertisements based on the business rules and the deterministiccriteria; providing a web portal that includes user accessibility to thevideo advertisements and the video advertising data for a user toanalyze; and providing notification of the availability of new videoadvertisements for review.
 2. The method of claim 1, further comprising:screening the video advertisement data for at least one of illegalcharacters and undesired characters, and editing the video advertisementdata to remove illegal characters and/or undesired characters from thescreened video advertisement data.
 3. The method of claim 2, furthercomprising: at least one of transcoding and transrating a file of thevideo advertisements; and storing the video advertisements, the screenedand edited video advertisement data, and transcoded and/or transratedvideo advertisements onto at least one of a LAN-connected computerserver and a WAN-connected computer server.
 4. The method of claim 2,further comprising: storing the screened and edited video advertisementdata in the memory.
 5. The method of claim 1, further comprising: atleast one of transcoding and transrating a file of the videoadvertisements.
 6. The method of claim 1, further comprising: analyzingthe video advertisements and video advertisement data.
 7. The method ofclaim 1, wherein the audio codec information comprises audio format,codec identification, sample rate, channels, bit depth, language, andbit rate, and wherein the video codec information comprises at least oneof video format, codec identification, aspect, frame rate, bit rate,color space, chroma subsampling, bit depth, scan type, and scan order,and wherein the video data relates to one or more of a container, a tag,an APE tag, and a subtitle, and wherein the container is at least one ofa MPEG-4, a QuickTime, a Matroska, an AVI, a H.264, a H.265, or aMPEG-TS, and wherein the tag is at least one of an Id3v1, or an Id3v2,and wherein the subtitle is at least one of a CEA-608, a CEA-708, aDTVCC, an SCTE-20, an SCTE-128, WebVTT, or an ATSC/53.
 8. The method ofclaim 1, wherein the web portal is arranged such that the users canselect or deselect a plurality of advertisement restrictions.
 9. Themethod of claim 8, wherein the plurality of advertisement restrictionsincludes restriction categories related to at least one of alcohol,ammunition, beef, casinos, competitor, condoms, feminine hygiene,firearms, gambling, pork, sexuality, tobacco, nudity, medicines to treaterectile dysfunction, violence, hate, seaworld, political, republican,and democrat.
 10. The method of claim 1, further comprising: utilizingindividual user criteria and the hierarchy of business rule criteria toeither approve or reject video advertisements; and communicating anapproved or rejected status of the video advertisements to anadvertisement server.
 11. The method of claim 1, further comprising:automatically approving or rejecting an individual video advertisementof the video advertisements to be placed in one or more video contentbased on a previously approved video advertisement, a previouslyrejected video advertisement, and/or content rating of the videoadvertisement.
 12. The method of claim 11, wherein the automaticallyapproving or rejecting is based, at least in part, on one or morespecific geographic regions.
 13. The method of claim 11, wherein theautomatically approving or rejecting is based, at least in part, oncriteria within the data structure of the business rules.
 14. The methodof claim 1, further comprising: automatically approving or rejectingmultiple video advertisements of the video advertisements to be placedin one or more video content based on the previously approved videoadvertisement, previously rejected video advertisement, and/or rating ofthe video advertisement.
 15. The method of claim 14, wherein theautomatically approving or automatically rejecting is based, at least inpart, on one or more specific geographic regions.
 16. The method ofclaim 14, wherein the automatically approving or automatically rejectingis based, at least in part, on criteria within the data structure of thebusiness rules.
 17. The method of claim 1, further comprising: utilizingan automated process to approve or reject an individual videoadvertisement of the video advertisements, and subsequently manuallyapproving or rejecting the individual video advertisement to be placedin one or more video content based on one or more criteria; and updatingthe business rules in the database.
 18. The method of claim 1, furthercomprising: utilizing an automated process to approve or reject multiplevideo advertisements of the video advertisements, and subsequentlymanually approving or rejecting multiple video advertisements to beplaced in one or more video content based on one or more criteria, andas applicable update the business rules.
 19. The method of claim 1,further comprising: automatically updating the business rules specificto an individual user based on at least one of one or more criteria, orspecific geographic regions for similar video advertisements.
 20. Themethod of claim 1, further comprising: providing access on the webportal to the business rules for user analysis; automatically updatingthe hierarchy of the business rules available to the users on the webportal based on at least one of one or more criteria and specificgeographic regions for similar video advertisements.
 21. The method ofclaim 1, further comprising: automatically updating application of thebusiness rules specific to an individual user, based on at least one ofone or more criteria, and specific geographic regions for similar usercontent categories.
 22. The method of claim 1, further comprising:providing access on the web portal to the business rules for useranalysis; automatically updating the hierarchy of the business rulesavailable to users on the web portal based on at least one of one ormore criteria and specific geographic regions for similar user contentcategories.
 23. The method of claim 1, further comprising: automaticallysignaling a status of rejected video advertisement based on one or morecriteria in real time or on a periodic basis to a video advertisementdemand partner.
 24. The method of claim 1, wherein providing a webportal includes providing one or more of: input user variables; usercontrol to automatically approve, reject and/or rate the videoadvertisements; user control to edit, append, and/or delete theassociated data and/or information; user control to approve or rejectthe video advertisements for production, and to update the datastructure of the business rules; user control to upload the videoadvertisements, the edited data and/or information and the transcodedand/or transrated video files onto one or more content distributionnetworks (CDNs) and/or one or more file backup providers; user controlto send a signal, and/or message by utilizing at least one of amessaging protocol, a flag, a text message, or an email reporting on theprogress of the video advertisement and/or video advertisement data; anduser control to log the progress of the video advertisement and/or videoadvertisement data to a LAN-connected logging server and/orWAN-connected logging server.
 25. A system for analyzing video contentfor approving or rejecting one or more video advertisements to be placedin one or more video contents based on one or more criteria, the systemcomprising: a processor; a storage; an operating system; a loggingmodule; one or more network interfaces capable of communicating with aplurality of video advertising networks and users; and a scriptingengine containing logic for: creating, modifying, and updating a datastructure of business rules; providing a web portal for the users toappend, modify, edit, and/or delete data within the data structure;creating, modifying, and updating a data structure of video filecharacteristics, information, and data; receiving a first video file;creating a system of transcoding, transrating, and transferring videofiles; determining the video file characteristics, information and data;analyzing the first video file characteristics, information and data inrelation to the data structure of business rules based on the analysisof the first video file in relation to the data structure of businessrules; determining a classification for the first video file, whereinthe classification is selected from at least one of a binary and aquantitative rating; selectively transmitting a signal pertaining to theclassification of the first video file; making the first video fileavailable for use based on the classification of the first video file;adding the first video file and first video file characteristics,information, and data to the list of available files available forreview in the web portal; updating the classification of the first videofile based on the input of the user; updating the business rules withinthe data structure based on the input of the user; signaling one or moreadvertising networks with the first video file rating based on therating of the first video file rating; updating the data structure ofthe video file characteristics, information and data; and transcoding,transrating, and/or transferring the first video file.
 26. A method ofdelivering live, 24×7 linear or on-demand video content, comprising:receiving a request for video content from a video-playing device orproxy that is coupled to a network; determining a device type and avideo player capability of the video-playing device; selecting a videocontent server based on attributes of the request for the video contentfrom the video-playing device and attributes of the video-playingdevice, wherein the video content server is capable of transmitting thevideo content; selecting zero, one or more video ads to be played withthe video content, wherein all of the ads selected have been whitelistedto be played with the video content; transmitting zero, one or morerequest for video ads to zero, one or more advertising networks or adservers, wherein the advertising network or ad server is capable oftransmitting the zero, one or more video ads; receiving zero, one ormore responses to the video ad requests identifying zero, one or morevideo ads; generating a playlist listing, in any order, a reference tothe video content to be requested from the video content server andzero, one or more references to the video ads to be requested from theadvertising network server and/or an ad proxy server; and transmittingthe playlist to the video-playing device.
 27. A method of deliveringlive, 24×7 linear or on-demand video content, comprising: receiving aplurality of requests for video content from a plurality ofvideo-playing devices or proxies, wherein each video-playing device orproxy is coupled to a network; determining a device type and a videoplayer capability of each video-playing device; selecting a videocontent server based on attributes of each of plurality of the requests,wherein the video content server is capable of transmitting the videocontent; selecting zero, one or more video ads to be played with thevideo content for each of the plurality of the requests, wherein all ofthe ads selected have been whitelisted to be played with the videocontent; transmitting zero, one or more request for video ads to zero,one or more advertising networks or ad servers, wherein the advertisingnetwork or ad server is capable of transmitting the zero, one or morevideo ads; receiving zero, one or more responses to the video adrequests identifying zero, one or more video ads; identifying zero, oneor more unused ads left over from prior requests for video content fromthe same video-playing device; generating a playlist listing, in anyorder, a reference to the video content to be requested from the videocontent server and zero, one or more references to the video ads to berequested from the advertising network server and/or an ad proxy server;and transmitting the playlist to the video-playing device.
 28. A methodof delivering live, 24×7 linear or on-demand video content, comprising:receiving a request for one or more video ads from a video-playingdevice or proxy that is coupled to a network; determining a device typeand a video player capability of the video-playing device; selectingzero, one or more video ads to be played with the video content;transmitting zero, one or more request for video ads to zero, one ormore advertising networks or ad servers, wherein the advertising networkor ad server is capable of transmitting the zero, one or more video ads;receiving zero, one or more responses to the video ad requestsidentifying zero, one or more video ads, wherein all of the ads selectedhave been whitelisted to be played with the video content; generating aplaylist listing, in any order, a reference to the video content to berequested from the video content server and zero, one or more referencesto the video ads to be requested from the advertising network serverand/or an ad proxy server; and transmitting the playlist to thevideo-playing device.